Weighted prioritizing layered computing system

ABSTRACT

The inventions relate generally to layered computing systems that provide public access to the content of the layers. Also disclosed herein are prioritization schemes usable in a layered computing system, including prioritization by layer type, by assigned priority weights, by access type, by sub-layers and by read-write indicators. Processes may further be associated to layers from which they originate, and priority given to associated layers thereby. Association may also be provided for installer services, thereby depositing an applications updates into its layer. Layers may also contain file reference information including exclusion or inclusion entries indicating what files may be written thereto. Paths recorded in layers may also embed variables to true paths on a layered system. Detailed information on various example embodiments of the inventions are provided in the Detailed Description below, and the inventions are defined by the appended claims.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. application Ser. Nos.10/459,936, 10/459,768 and 10/459,870 filed Jun. 11, 2003, U.S.application Ser. Nos. 11/026,520 and 11/027,489 filed Dec. 30, 2004, andU.S. application Ser. Nos. 11/081,856 and 11/082,194 filed Mar. 16,2005, each of which is hereby incorporated by reference in its entirety.

BACKGROUND OF THE INVENTIONS

In the last two decades computers have developed into sophisticatedmachines having powerful processors and large amounts of memory andlocal data storage. A modern computer has installed thereto a largeoperating system, which today includes not only low-level functions foraccessing input, output and storage devices, but additionally librariesproviding common functions to applications, graphical windowing systems,and applications to perform administrative functions, data accessfunctions, and even multimedia and entertainment functions. The commonpractice of using applications requires the installation of anapplication's executable, configuration and data files to local storage,although some applications and systems extend this to use of networkdrives as well. Today's computers also multitask, and permit more thanone application to be installed and executed thereon concurrently. Thissophistication in the operating system in combination with the largenumber of potential applications from diverse sources has made theadministration of a typical modern computer more difficult.

With the advent of graphical operating systems, users were offered a wayto visually interact with a computer. This visual interaction madepossible a new hierarchical organization to the computer presentation,typically including a top-level presentation, for example a ‘desktop’with a top level ‘start’ menu, and further including sub-presentationssuch as application windows. Executing applications under that mode maybe performed by acting on icons and menu items, relieving the user fromthe burden of having to know the logical location of items in afilesystem to use them. These icons, shortcuts, links and menu items allpoint to an executable or other object at their true reference points.If the reference object is moved to a different location in thefilesystem hierarchy, the link to the object becomes broken andnon-functional; in some operating systems the system may attempt toresolve the new location of the object and fix the link.

In personal computers of the early to mid-1980s, applications and datawere typically stored to a floppy disk, with little to no othernon-volatile storage available to programs. Those disks could betransported between computers of the same type, thereby making thoseapplications portable. The execution of those applications, however, wasfrom the command line, which required some user expertise. A user, forexample, might need to know that an application's executable was locatedon drive ‘0’ or ‘a:’. Should an application disk be inserted to a seconddrive, the application might be required to be reconfigured to referencedata and configuration objects on that second drive. The computer andoperating system makers of the time largely left the problem ofapplication mobility (moving an application to a different drive orlocation) unaddressed, which required users to maintain manyapplications in static locations even though stored to floppy disks.

Other types of portable storage have been used in the past. One earlyexample was a cartridge including a read-only memory and a card-likeinterface mating to a socket, for example in a game console. Thosecartridges contained no file-system, but rather were presented asinstructions and data at particular addressable memory locations. Inaddition to floppy disks, mentioned above, high density magnetic mediacartridges have been used, for example “Zip” disks. The improvementtherein related mainly to the amount of data that could be stored on theportable media. Other examples include optical and magneto-opticaldisks, some of which are commonly known as CDs and DVDs. The advent ofthese permitted the cheap distribution of software and data, supplantingthe use of floppy diskettes and permitting the growth of softwareapplications to many megabytes. Those software makers have takenadvantage of the increasingly large amounts of local hard drive storagefor applications, and have largely not attempted installations otherthan to a local hard drive. Today, nearly all software packages performan installation step in which the application's files are installed to alocal hard drive of a computer.

Presently, the most convenient uses of applications require installationof an application to a local hard drive or use of applications stored onportable media in a known or determinable position in the filesystemhierarchy of the computer. In the latter use, the application might beused on more than one computer, provided that the user has sufficientexpertise to configure the application and operating system with anynecessary icons, drivers, and directory locations.

Additionally, prior computing systems have been susceptible toapplication conflicts with the host operating system (OS) and otherapplications. When an application is installed to an OS, a number ofglobally accessible files are often placed to the computing system,including for example shared libraries and system configuration. Thoseshared libraries are often provided in different versions, withapplications requiring one version or another. A mismatch between alibrary version and a version required by an application sometimesresults in that application crashing, becoming inoperable, or exhibitingother errors. Shared configuration elements are sometimes globallyavailable to applications, which may write a favored configurationthereto. Following a write to that configuration other applications maybe unable to read the configuration properly, or may be unable tofunction under a new specified configuration. Thus it is that followingthe installation of an application to a computer, other applications maystop working.

Installing a number of applications to a computer can be something of ablack art. An administrator may, with good intentions and understanding,install several applications to a computer. Upon testing an installationor during use, the administrator or a user may discover that one or moreapplications operate errantly or not at all. It is sometimes notapparent which applications are in conflict. The administrator may entera procedure in which applications are uninstalled from the computer in aprocess of elimination to find the offending applications. Sometimesde-installation programs do not remove all installed files, in whichthat procedure may fail to locate the problem. The administrator is thenrequired to continue by creating a clean (or “virgin”) installation, andinstalling applications one at a time until the problem is located.

When applications are found to conflict, a choice must usually be madeas to which one will be installed. One of the applications is sometimesinstalled to a different computer to avoid the conflict. If conflictingapplications must be installed to a single computer, a new version of atleast one of the applications must be sought and purchased from thesoftware vendors. A non-conflicting version may not be available,especially if a vendor is small, not supporting the application, or nolonger in business.

Snapshot utilities are available, which generally operate to create adatabase of all files and registry settings on a computer. Prior toinstalling an application, a snapshot is taken of the files and registrysettings. The application is then installed, and tested. If theapplication fails to work satisfactorily, the system can be restored bycomparing the existing files and registry settings against the snapshotand removing installed files and otherwise restoring the system asbefore. Snapshot utilities have several limitations. First, if a newlyinstalled application causes a prior installed application to fail, itis often not possible to simply revert to a snapshot made prior to olderapplication installation, especially if there have been otherapplications installed in the interim. The administrator may be requiredto revert back to the earlier snapshot, and then re-install theintervening applications and the new application. Additionally, thereare usually a limited number of snapshots that can be stored, and thus arequired snapshot may not have been retained when found to be needed.

Likewise, a system may be restored to an earlier state if backups havebeen made. That restoration process, however, usually involves asignificant amount of time and destroys all data recorded to the systemafter the time of the backup.

A current practice of maintaining computers is to image the hard driveof a computer while in a working state. If the computer becomesunstable, or if undesirable content appears on the computer, thecomputer's drive is restored using the earlier made image. This practiceis lacking in that all changes made following the image creation arewiped off the system when the computer is restored, including user filesand other applications.

Also, some applications are not provided with an uninstall program. Tode-install those applications an administrator is required to know wherethe application files and settings reside in the system, and remove themmanually.

BRIEF SUMMARY OF THE INVENTIONS

The inventions relate generally to layered computing systems thatprovide public access to the content of the layers. Also disclosedherein are prioritization schemes usable in a layered computing system,including prioritization by layer type, by assigned priority weights, byaccess type, by sub-layers and by read-write indicators. Processes mayfurther be associated to layers from which they originate, and prioritygiven to associated layers thereby. Association may also be provided forinstaller services, thereby depositing an applications updates into itslayer. Layers may also contain file reference information includingexclusion or inclusion entries indicating what files may be writtenthereto. Paths recorded in layers may also embed variables to true pathson a layered system. Detailed information on various example embodimentsof the inventions are provided in the Detailed Description below, andthe inventions are defined by the appended claims.

DESCRIPTION OF THE DRAWINGS

FIG. 1 conceptually illustrates the components of an exemplary layeredcomputing system.

FIG. 2 illustrates the operation of a simple layered computing system.

FIG. 3 conceptually shows an exemplary layered computing systemarchitecture.

FIG. 4 conceptually illustrates one storage organization for a layeredcomputing system.

FIG. 5 conceptually shows the operation of an exemplary layeredcomputing system supporting ion layers.

FIG. 6 conceptually illustrates exemplary layered system activitieswithin the system, process and FSL spaces.

FIG. 7 conceptually illustrates priorities in an exemplary layer-typedlayered computing system.

FIG. 8 provides a visual description of one application of variablizedpaths in a layered system.

FIG. 9 visually depicts a process of associating child processes tolayers.

FIG. 10 visually depicts a method of releasing layer priority records onprocess termination events.

FIG. 11 illustrates one method of prioritizing layers for requestsincluding a special search for processes assigned to application layers.

FIG. 12 illustrates activity for a close event in one exemplary layeredsystem.

FIGS. 13A and 13B depict a method of performing priority searches in anexemplary layered system.

Reference will now be made in detail to some embodiments of theinventions, example of which are illustrated in the accompanyingdrawings.

DETAILED DESCRIPTION

For the purpose of simplifying the discussion herein, several exemplarycomputing devices are referenced. Those devices are typically aconventional personal computer or workstation having a CPU, memory,display, keyboard, mouse, and at least one fixed disk. It will beapparent to one of ordinary skill in the art that the concepts disclosedherein may apply equally to other computing systems that are notpersonal computers, for example diskless workstations, headlessworkstations or servers, embedded systems and many other types. Hereinit is contemplated that the inventions may be applied to these and othercomputing systems, both existing and yet to be, using the methods andprinciples disclosed herein. Likewise, although many of the examplesbelow refer to a system with a single base filesystem, the concepts,principles and examples disclosed below may be extended to providelayered services across several or many accessible filesystems, as willbecome apparent from the discussion below.

Likewise the discussion below speaks of registries and registrysettings, which are specific to Microsoft Windows™ operating systems. Itwill be recognized that registry settings are merely configuration forthe operating system and applications installed to a computing device,accessible through a system-wide API. The meaning of registries andregistry settings is therefore extended to future Windows operatingsystems and operating systems other than Windows, where equivalentstructures and access facilities exist thereon.

Other objects, methods and techniques are also discussed below inreference to particular examples; the reader will appreciate that theuse of examples below is merely for convenience, and that the objects,methods and techniques disclosed herein may be applied beyond theexamples without departing from the disclosed concepts.

General Concepts

A majority of the concepts disclosed herein relate to a layeredfilesystem. In an ordinary filesystem, an operating system applies afile pathname to a filesystem to reach a file object, which might exist,for example, as a series of data blocks on a hard disk. Some operatingsystems permit access to a plurality of filesystems, each existing in aconfined name space. For example, in a Microsoft Windows environment afile name is preceded by a drive letter, for example “C:”. A Linuxoperating system also utilizes prefixed directories; some Linuxdistributions provide for filesystems to be mounted under the “/mnt”namespace. In any case, such an operating system can determine thesingle location of access for a file by an evaluation of file pathnameby extracting and examining the relevant portion thereof.

An operating system that supports filesystem layering can provide formore than one location of access for a particular file pathname. Such alayered operating system can therefore look in two or more repositoriesof file objects, which are referred to herein as filesystem layers ormerely “layers.” As there is more than one potential location for a fileat a particular pathname, the operating system performs an extracomputing step in order to determine the “owner” layer of an accessedfile, which is the layer applied to the file access. For file readaccesses, this generally requires a search of the layers in an order ofpriority to find the layer with highest priority that also contains afile object corresponding to the requested pathname. For writ accesses,this generally requires a search of the layers, also in an order ofpriority, to determine the highest ranked layer to which the file may bewritten. For example, some of the layers might be configured to beread-only, while others are writable.

FIG. 2 provides a simple illustration of layering system concepts. Firstin this example, an application 200 is running on a layered computingsystem, or simply a layering system. This application could be anapplication provided with an operating system, such as a file exploreror shell, or might be a third-party application installed later. Thiscomputing system contains a base file system 206, and two layers labeled“A” and “B”, 204 and 202 respectively, which are enabled for accessing.A base file system is also maintained, which is the default file system(present even if other layers are not.) Base file system 206 willnormally contain the fundamental portions of the operating systemnecessary to boot up and execute basic applications and functions. Inthis example layer B has general priority over layer A, which in turnhas general priority over the base file system A first file access 208is made by application 200. The layered computing system determines theowner of the file being accessed. Finding an entry for file access 208in layer B, the corresponding file in layer B is opened and returned tothe application. The file access of 208 might also correspond to filesin layers A or the base file system, however layer B is determined to bethe owner as it has priority over layer A and the base.

Another file access 210 is made by application 200. The computing systemdoes not, however, find a corresponding entry in layer B. An entry isfound in layer A, which has priority over the base file system. Again,if a file existed in the base file system corresponding to the fileaccess, the file reference in layer A would be accessed because layer Ais found to be the owner with priority. The computing system is not ableto find corresponding entries in layers A or B for file access 212, sothat access is made to the base file system. Now this priority is merelyexemplary; examples below will demonstrate priorities that vary betweenlayers, applications and file types.

The contents of layers 202 and 204 can be presented or made inaccessibleto the operating system by enabling and disabling the layer (thelanguage below may also use the terms “activate” and “deactivate, butthe operation is the same.) Thus the contents of a layer are organizedin a single container that can be presented, withdrawn, moved or deletedas a unit. A layer that is enabled for access to the operating systemoverlays its contents to the base filesystem, and thus the layercontents appear to the operating system in their ordinary and expectedlocations. If a layer is disabled or removed, the layer contents nolonger appear to the processes of the operating system, and thus a layerprovides a convenient way to deposit or remove files from a computer asa higher-order unit.

For registry entries, these may be managed much like files. Registryentries, as in some operating systems, are maintained as a set for theoperating system and generally consist of a name and a value. Each layermay contain a list of name/value pairs, the names being applied inpriority as with file references and the value being either reported(for a read) or recorded (for a write or deletion.)

Application Layers

Certain of the systems disclosed herein relate to application layers,which are layers that contain the file objects and optionally registryentries of one or more applications. An application in this sense mightbe an application in the ordinary sense, such as a word processor and/oroffice suite, a browser, a game or the like, but can also include anysoftware add-on to a basic operating system. Thus an application layermight include shells, system tools or even a service release for anoperating system. A layer intending to isolate a host-installableapplication may have file references that reflect the application's filereferences as installed to the base filesystem of the base operatingsystem. Thus the application's files, data and system accessibleconfiguration can be presented as if they resided in their respectiveordinary locations even though encapsulated in an application layer,with the appearance to a user that the application is installed in theordinary fashion with the expected functionality.

In a system that provides for the enablement of several applicationlayers, the application layers can be organized to separate or isolateseveral applications, which may provide certain benefits. First, theapplications appealing to be installed to a computer can be modified bymerely commanding enablement or disablement of the application layers.For example, an organization might choose to maintain computers with aparticular operating system, with a different set of applicationsprovided for individual users according to their needs. Thus theaccountant would have the application layer containing the accountingsoftware on his computer, and the graphics designer would have thegraphics application suite layer on hers. Versions of applications mayalso be the basis of a layer. For example, an Internet browser version1.0 might be encapsulated in an application layer on a user's computer.When version 1.1 of the browser is released, it can be captured to alayer, which layer is imported or deposited on the user computer. Thelayer containing version 1.1 is enabled, and the version containing 1.0disabled and optionally removed from the user computer. Should, afteruse, version 1.1 prove too unstable for regular use, that layer can bedisabled and the layer containing version 1.0 be re-enabled withoutundertaking any application installation activities. Of course, theseprinciples apply to computers other than user computers, for exampleserver computers or embedded systems.

The use of an application layering system as given above providesseveral additional advantages. If applications are stored individuallyin layers and if priority is given to an applications layer first,interactions between application files may no longer occur due toconflicting shared libraries (DLLs), as each application ‘sees’ onlyit's own installed libraries first. Libraries in the base operatingsystem are seen next, those base libraries optionally preceded bylibraries from other layers if desired.

By maintaining an application encapsulated in a layer, the applicationmay become transportable from computer to computer. If the applicationlayer contains the executables, libraries, configuration files and allnecessary and/or dependent files for execution of an application, thatlayer may be deposited to any computer with an operating systemcompatible with the application. On a computer system that supportsregistries, an application layer may also contain registry entries ordeletions. Thus if an application is captured to a layer on a firstcomputer, the layer can be copied or located to a second computer whilemaintaining application functionality. As will be seen, a layer canprovide a package that can be compressed, encrypted or transportedconveniently. Thus, using a layering system application vendors canprovide ‘pre-installed’ applications as layers on CD-ROM or other media,or as a download, those applications being pre-tested and guaranteed towork with a high reliability. A layer also provides a convenientcontainer to limit access to an application, for example for timelimited use or license key access.

The references of a layer may also contain file or registry deletions.Those are references that specify the absence of a file or registrysetting, and thus the file or registry setting is shown to be deleted ifthe containing layer takes priority over another layer, or the basefilesystem, that includes a corresponding registry entry or file.

Sublayers

Application layers may be composed of a single layer, containing thefiles and other content of the application, which layer may indicatethat it is read-writable or read-only, allowing or preventing changes tothe application layer. For a read-write layer, certain file writes canbe directed to the layer determined, for example, by rules specifyingsources (from particular application processes), destinations(directories), or file types. For a read-only layer, writes are directedpast the layer to the next layer in priority.

In some layered systems, layers may contain sub-layers. A sub-layer issimply a layer that is joined to a parent layer, whereby the sublayer isconfigured to be enabled with the parent. Thus as the system receives acommand to enable or disable a layer, its associated sublayers are alsoidentified and enabled or disabled in tandem. The data of a sub-layermay be logically associated to its parent layer by including itsinformation in the data of the parent, although a sub-layer can bestored apart if desired.

One use for sublayers is to separate a file portion that is anunchangeable “install” portion from a user configurable portion. Forexample, a word processor might by default include a set of executables,help files, configuration, links and other data. As the word processoris used, the user might be directed to enter his personal informationincluding his name and address, and through using the application mightchange certain configurable items such as the tap stops, toolbars, andthe default printer. In another example, a user might configure an emailclient with an email address, the address of an email server, and apassword. These user configurations are usually stored by theapplications to files, which are intended to be written in the base filesystem at some location.

An application layer can be configured with a read-only “install”portion that contains the base application with initial userconfiguration, and an empty read-write sublayer. As the user modifiesthe application configuration these changes to the file system arecaptured in the read-write sublayer. The layered computing system candetect that a write operation originates from an executable residing inthe application layer, and record the write operation to the associatedread-write sublayer thus storing any application configuration changes.This may be done by prioritizing the application layer and itsassociated sublayers specially relative to other enabled layers. Anapplication read-write sublayer may also be prioritized before itsapplication layer, so changes to application files, such asconfiguration files, can be seen by processes running on the system.This sublayer prioritization may be applied to the layers associated toa process as well as to application layers generally. If desired, thesystem may also discriminate files that are user files, for exampledocuments or email attachments, that should reside elsewhere in thelayered system hierarchy.

An advantage of pairing a read-only layer and a read-write sublayer inan application layer is easy restoration. To restore the application toits original installation state, it may only be necessary to erase ordelete the read-write sublayer. For example, if the application were anemail client, the user might be exposed to any number of viruses. Shouldthe user mistakenly open an infected email attachment, the damagingchanges that would have been made to the operating system are capturedin the read-write sublayer. Upon discovering the infection, a managerapplication can receive a command to reset the application's read-writelayer, which is then identified and the read-write sublayer can bewiped, for example by removing all the file objects therein. Thus theintegrity of the base operating system may be preserved as well as otherapplications installed to the computing system.

Sublayers can also be attached to other sublayers. In the exemplaryimplementation a parent application is permitted to have one sublayer.The sublayer can specify a further sublayer, and thus an entire chain ofsublayers can be defined through that method. But regardless of howsublayers are related to their parent sublayers, the sublayers of aparent are, in general, enabled at the same times the parent layer isenabled.

Conceptual Example

The principles described above can be understood operationally, asdepicted in FIG. 5. A base operating system (base OS) 524 providesfacilities for interactions with files stored to local storage 526,which for example might be a hard disk drive, and optionally to anetwork directory 528, with those files generally being presentedsimilarly as with files on local storage 526. Base OS 524 includes basefilesystem drivers 22, which may be integral to the base OS or might bemodular in nature, and provides file access to applications runningunder the base OS 524. A layered driver 505, in this case an FSL systemdriver as described below, is installed to provide access to layers aswill presently be described. Further in this example, an applicationlayer 506 is enabled for use by the system by way of driver 505 toprovide access to files contained in the layer. Another layer 516 mayalso be enabled.

In the example of FIG. 5, a file explorer application 502 is providedwith base OS 524. The file explorer may make requests for directorylistings and for file accesses. In a first access 530, the desktopapplication requests access to a file reference by using the usualprocedure calls. On installation, the layering driver 505 has modifiedthe destination of those procedure calls so that it may process themprior to processing by the base OS drivers 522. First access 530 isfirst reviewed by the layering driver 505 by reviewing application layer506 for the presence of a file entry matching to the access reference.For the first access, a match is not found and the access is permittedto progress. If other layer 516 is enabled, it is in turn searched for amatching file entry, in this example after application layer 506 due tothe secondary priority placed to other layer 516. If after searching theenabled layers the layering system drivers 505 finds no entry matchingthe first access reference, the first access is permitted to follow thenormal route of access through the base filesystem drivers 522, whichmay result in a file access in local storage 526 or network directory528.

A second file access 532 is made from explorer 502, this time in theform of a command to execute a file, for example by a userdouble-clicking on an icon. For access 532 an executable file entry 508is located in application layer 506. The locating of entry 508 resultsin a corresponding virtual reference, which is used to reference thedata corresponding to the file entry. That data is loaded into RAM 534and executed, resulting in a new application process 504. Layeringdrivers 505 notice that application process 504 is started fromapplication layer 506, and make a relation 514 of that process to thelayer from where it came, for example by referencing the PID ofapplication process 504. The execution of application process 504results in a request to load a library, which in turn results in a fileaccess 536 for a “dll” file. Layering drivers 505, utilizing therelation 514 made earlier, detect that application process is related toapplication layer 506, and first looks for the file reference in theapplication's layer 506. The layering driver 505 finds an entry 510 forfile access 536 in the application layer, the file entry 510 referencinga library specific to application process 504. That library is loadedinto memory using the same procedure as the ordinary procedure providedby the base OS 524, with the exception that the read calls areredirected into layer 506 using a virtual reference.

Application process 504 makes a read request 538 for an additional file.No entry is found in related application layer 506. The layering driverscontinue to search for a file entry corresponding to the reference inother layer 516, where a file entry 518 is found to match. The data ofthat entry is delivered to application process 504, even though the fileentry is located in a different and lower-prioritized enabled layer. Ina third file access 540 layering drivers 505 find no corresponding entryin enabled layers 506 and 516, and pass that access to the basefilesystem drivers 522. A fourth file access 537 is an access to writeto a file. In the example of FIG. 5, a write layer 520 is enabled tocapture changes that would have been made to unprotected areas ofaccessible filesystems, for example the base operating system or aprotected layer. Also in this example, application layer 506 isconfigured as a read-only layer and a file entry 512 exists in thatlayer for the write reference 537. Layering drivers 505 do not carry thewrite operation to file entry location 512, but rather create a newentry in write layer 520 for the written data, or modify a correspondingpre-existing entry in the write layer 520. Write layer 520 isprioritized over application layer 506 by the layering driver 505 toread modifications to a file reference first rather than the file dataas originally created in the application layer.

Now in the example illustrated in FIG. 5, only references to files arediscussed References to a registry, for example a system registry, maybe handled in a similar fashion to file references by substituting fileobjects for a registry reference and by substituting a filesystem for aregistry object, for example an “.ini” or other registry file.

The above exemplary layered system is an example of a public layeredsystem. In that type of layered system, applications not stored to acontaining application layer may be given access to its contents. Thusprocesses such as explorer 502 can access the contents of applicationlayer 506. In contrast, a “layered” system may be constructed with aprivate context. In that type of system, the contents of “layers” aremade available only to a particular parent process, which might be awrapper application that bootstraps drivers to intercept file accessesfrom processes started from a particular layer. Private context systems,however, do not permit applications generally to access the files withinthose “layers.” A file explorer, for example, could not “see” into aprivate contextual layer either to execute an application or to accessdata files within. The contents of such a “layer” are thereby sandboxedand isolated from most if not all other applications on the computer.Additionally, because those layers are sandboxed from other layers, thestacking of layers is not possible; the choice of layers in a privatecontext system is therefore simplified to relations between a wrapperapplication, it's child processes and the “layer” it is associated with.

A public context layered system, by contrast needs no wrapperapplications to access and/or execute the contents of layers, as thosecontents appear to all applications generally (provided access to thelayers is not restricted, for example by encryption). Additionally,several layers can be presented on the system at the same time toapplications generally, which provides flexibility in the creation oflayers and layered application frameworks. Most apparently to a user,the contents of a layer become immediately and generally accessible uponenablement of the layer without additional steps and complication.

Creation of Application Layers

There are many possible ways of creating an application layer. Onemethod reflects the usual method of creating an application installprogram. The first step is to assemble all the application parts, forexample by executing the necessary compilation and assemblage steps. Thesecond step is to create a manifest of the pairs. A final step is toinsert the parts as manifested into a layer, becoming the applicationlayer. This is much like the creation of an extractable installationfile, except that an installation program for depositing files andadjusting installation paths for the application on the target systemmay not be necessary. That, and other manual methods, may be used.However, there are a number of automated methods that can observe anapplication installation and thereby create a corresponding applicationlayer.

These automated methods utilize a “capture” operation, which from aconceptual standpoint observes the regular installation orde-installation of an application to discover which files belong to anapplication. A capture operation is generally started and ended, anduses the layering software to intercept operations that install, delete,rename or modify files and configuration such as a registry. If thelayering system supports layers having both a readable and read-writableportion, the capture operation may record changes to the read-onlyportion, which becomes effectively locked when the capture operation isended. During the capture operation changes made by the installationprocedure do not affect the base system, but are rather recorded to thenew layer.

A first layer creation mode is simply called “capture” mode. When thatmode is enabled, all operations by any application to create, modify ordelete files are entered into a layer. This mode is especially helpfulin situations where it is desirable to create a new layer for one ormore applications to be installed to the computing system. In an exampleof a capture mode operation on a Windows platform, a user first enablescapture mode. The user then executes an application installationprogram. During the install, all of the applications shared DLLs,registry entries, and .ini files that would be directed to the Windowssystem directories become trapped in the capture layer. Applicationfiles that would be placed on file systems managed by the OS are alsoredirected into the layer. All of the captured data is held separatefrom the regular OS either locally or remotely in a new layer, a datafile, hard disk partition, or some other container.

A second layer creation mode is referred to as “capture by PID” mode.That mode is similar to “capture” mode, with the difference being thatonly changes made by a particular process ID (PID) or one of its childPIDs are captured.

A third layer creation mode is called “delete capture” mode. This modemay be thought of as the inverse of “capture” mode. Delete capture modeis intended to track all of the file system and registry deletions thatoccur and place those files and registry entries into a new layer. Thesoftware (driver) is hooked into the system so that operations thatdelete, rename, or modify file system or registry so they can be copiedto the capture layer before they are modified. This mode may beparticularly helpful to create a layer of an already installedapplication. The user enters “delete capture” mode, following which theuser activates the application's deinstallation program. As theapplication's uninstall program removes files and registry settings,they are copied to the new layer. When the uninstall is complete, theuser exists delete capture mode. At that time the application does notexist in the regular file system or registry, but can be activated bythe user as it appeared before the uninstall operation by activating thenewly created layer.

A fourth layer creation mode is called “delete capture PID” mode. Thatmode operates in similar fashion to delete capture mode, with thedifference that only changes made by a particular PID and child PIDs aretracked, rather than system-wide changes.

The tracking of file and registry writes may be performed generally orwith reference to a parent process, as will become apparent from thedisclosure below. Finally, after a capture operation a layer may beadded to or files removed from the set of captured objects manually,should adjustments need to be made.

Architecture

A computing system supporting layers may be configured as conceptuallydepicted in FIG. 1. A base operating system 110 forms a platform withwhich applications can be run and files can be accessed in file systems.Base operating system 110 further has registry settings, globallyavailable to applications for reading and writing. The system haslibraries 108 for executing the functions of the operating systemincluding operating file systems and registries, and other operatingsystem functions. Tied into libraries 108 are layering system librariesand/or software 106 which intercept file system and registry accessesfrom applications 104. As accesses are received from applications 104,the layering system software 106 performs computations to determinewhether the accesses should be permitted to continue to the baseoperating system 110, or should be redirected to layer information 112,the information relating to the contents of file objects and registrysettings. A layer manager application 100 may be provided to permitcontrol and configuration of the layering system software 106 through amanagement API and library 102.

A layer may take many forms, but in essence, a layer is a container offile objects and/or registry settings, accompanied by the names andpaths to those objects when overlaid on the regular file and/or registrysystems. For applications that do not utilize a registry, an applicationlayer and system need not contain or support registry settings. Layersmay be stored to a storage device 402 as shown in FIG. 4, which might bea hard drive or other local storage. Although it is convenient to storea layer to a local non-volatile storage medium for long-termavailability, a layer can also be stored to memory, a network or otherlocation if desired. The computing device of FIG. 4 includes a processor400, which may also have peripheral devices attached such as memory,input devices or output devices as desired, and interacts with one ormore storage devices 402 thereby providing storage for the processor. Onstorage 402 is a base operating system 408 and applications 410. Anumber of layers 404 a-n are also contained on storage 402, each havingapplications 406 a-n. These layers may be stored in a block as a singlefile, as a block of sectors on the hard disk, in a directory structureon a regular or base filesystem (as will be discussed below), or in anyother convenient form. For example, files and registry settings may bestored in a regular file system, where the file paths are stored under adirectory and in a directory structure that mirrors the file objectlocations in the regular file system. Such a mirrored layer system maybe organized in a common directory, with one subdirectory per definedlayer, each containing a mirrored directory structure of the underlyingfile system. For systems that utilize a mirror structure of anunderlying file system, it may be desirable to hide the mirror structurefrom applications, except perhaps a manager application, so as toprevent accidental data modification, loss, or meddling. A layerdefinition may include layer properties, flags and settings, layerinclusive files, references to those files, registry settings andlocations, and a manifest or directory those file and registryreferences.

A layer may be packaged in a form transportable from an individualcomputer, which packaging is referred to here as exporting a layer,which produces an exported layer. An exported layer contains theinformation contained in the original layer, but is packaged into atransportable form, for example in a single file that can be managed,copied, downloaded or recorded and moved. For example, an exported layermay utilize an archival format, such as a zip or tar format.Additionally, dependent sublayers (described below) may also be packagedwith the exported layer for convenient management.

Variablization

It can be advantageous to generalize, or variablize, pathnames in alayered systerm. Some operating system types permit certain system anduser directories to be renamed or located in various locations, whichcan impede the portability of a layer. Variablization provides a way togeneralize a layer and make it operable in the face of variations ofthese directories.

It may optionally be desired to include variable handling with regard tofile system paths and registry paths. The location of a file or registrysetting specified in a layer may include one or more variables, so as topermit relocation of that object. A variable may be denoted in manyways, for example by surrounding the variable name with percent “%”characters. The source of some variable names and values may be from theenvironment. For example, Windows operating systems set the “WINDIR”environment variable to the location of the OS system subtree, forexample C:\windows. Including the WINDIR variable in a path may permitfiles of a layer to be moved from one Windows system to another,especially if the OS system subtree resides in different locations onthe computers. Other variable values may be supplied at runtime, forexample a “CURRENTUSER” variable. In that example, the CURRENTUSERvariable is set to a user's login name while that user is logged in. Oneuse of the CURRENTUSER variable is to provide a layered file referencefor a global file that appears in each user's profile directory. Yetother variable names and values may be stored in a layer definition. Amanager application may provide editing facilities for changing thoselayer-defined variables, and for editing the pathnames of virtual files.

FIG. 8 provides a visual description of one application of variablizedpaths in a layered system. First, certain variables are determined atboot time 800 and maintained afterward, such as those pertaining to theoperation of the system, for example a system directory of which a“WINDIR” variable may be appropriate. Other variables are defined when auser logs in or is otherwise identified 802, such as the “CURRENTUSER”variable or a variable to a user directory such as the user's profiledirectory named “USERPROFILE”. Other variables might be defined at othertimes, as desired. The result is a set of M variables 804 that may beapplied for accesses to a filesystem or registry. In a multi-usersystem, each user may have a list 804 that corresponds to her usersettings, and in that system each file or registry access is preceded byan identification of the user assigned to an access-requesting process.As open requests, and other file or registry requests, containing anamed or path reference are received 806, those references are expandedto their full long pathnames. A path reference might be a path to a fileor a directory, or other filesystem path. Those full representations arethen evaluated 808 against the set of variables, and where a variablesetting can be found in the full pathname. The result of evaluation 808is a set of N paths containing variables as described above, and theoriginal full pathname.

In the example, a number of layers 812 a to 812 n are enabled in thelayered system. The contents of each layer are compared againstvariablized paths 810 for a match. If the original request 806 was anopen, or other operation reporting a single file, the comparisonscontinue until a match is found and a file reference 814 is producedtherefrom. For requested operations 806 that report multiple files, aset of matches 816 is constructed from the comparisons, which may bereturned through ordinary file operation functions. As the layers aretraversed, a base filesystem 812 base may be encountered. In that case,only the full pathname is compared, as variables are not applied toreferences outside the layers.

Variablization may also be extended to registry values. If a registryvalue is retrieved from a layer in response to a request, the variableentries in the layer representation are replaced by their variablevalues in the system at the time of the request. For setting variablizedregistry entries to layers, that may be conducted as for a file writeoperation search, and also detecting a request to set a registry entrycoupled with a determination that the setting is destined for a layer.Following that, the value of the registry setting is examined for avariable setting contained within, identifying a variable that has apath value included in the value to be set in the registry entry. In theexemplary system below, if two variables may be applied, the variablewith the longest value (most directory steps) is chosen for thesubstitution. The value of the applicable variable is substituted intothe value to be set, and the substituted value is recorded in thedestination layer as a registry entry.

The setting of file references and registry values follows theevaluation 808, however it may be helpful to store only one variablizedrepresentation rather than the several of list 810. The selection ofrepresentations is made, for example, by using the longest variablerepresentation as described below for the exemplary implementation.

Priority Schemes

Many possible priority schemes can be used with a layering system, andcertain of those schemes are conducive to use with application layers.In a first scheme, application layers are simply overlaid over the basefilesystem, either with a general higher or lower priority. Where filesare duplicated between an application layer and the base, for example a.dll library, the file provided by the application layer will takeprecedence in a system prioritizing application layers more highly.Alternatively, a lower application layer priority will permit base filesto override application files. Either can provide advantages anddisadvantages; the advantage of preferring application layers providesfor use of updated libraries and system files by inclusion in theapplication layer. On the other hand, preferring the base ensures use ofknown files which may assist stability and debugging. But in eithercase, should the non-preferred layer contain an updated file it will beoverridden by the system in this simple scheme.

One solution to this problem is to include additional layer types. Notonly could a layering system include application layers, but also patchlayers. Thus a layering system might give higher priority to applicationlayers, but an even higher priority to system patch layers. Thus anupdated system library could be delivered in a patch layer, which wouldoverride any corresponding libraries located in application layers. Thusa layered system may rank layers identified as one type over otherlayers identified by another type. This concept can be extended toinclude patches of patches, and so forth, which layers may optionally beprovided with a priority setting.

Those schemes are useful in prioritizing files provided by anapplication or operating system provider. Other schemes are useful toprioritize user written files. A first method is simply to permit userwrites to be recorded in a base filesystem. This provides a minimalapplication layer system, but does not protect the system againstmalicious or accidental damage.

An improvement can be made by providing a writable layer that capturesfiles written generally. This layer might be global to the entirecomputing system, or instead a writable layer might be made for eachuser. It may be necessary in those schemes to discriminate betweenwrites made by applications and other writes made by system processes soas not to impede system operation.

A prioritization by layer type may be structured in many ways, butgenerally certain layer types may take priority over other layer types.For example, user layers may take priority over a base filesystem tocapture writes made by user applications. Likewise, it may be desirableto prioritize user layers over application layers to prevent usermodifications to application-related files. Application patch layers maytake priority over ordinary application layers to overwrite old files tobe patched. Likewise, system patch layers may take priority over a basefilesystem. A security patch intending to fix an exploit may likewisetake priority over both base filesystems and application layers.

A significant improvement can be made to a layering system supportingapplication layers by tracking processes against the application layersthat they spring from. In such a system the layered system drivers, oranother component, maintain a relationship between processidentifications and application layer unique names. The association canbe made, for example, when an executable is started from an applicationlayer. That system then operates under the presumption that requestedfiles will be first intended to be found in the application layer,followed by other layers or the base. That system can make a furtherpresumption that file write operations from an associated process shouldbe associated with the application layer in a read-write sublayer orother location. Exceptions to those presumptions can be made, some ofwhich are discussed below.

Referring now to FIG. 11, one such method of prioritizing layers isconceptually depicted. The method begins by an open function call 1100,or another function to access a file object or perform a file operation.If the calling process is related to an application layer, it isidentified 1102. Variablization 1104 may also be performed. After layeridentification, the method branches 1106 to one of two search methods.If the process is not related to an application layer, a normal prioritysearch 1110 is performed, with general prioritization. Otherwise, asearch is performed that favors the prioritization of the processesapplication layer 1108, which may have the effect of speciallyprioritizing file accesses to the application layer to which a processis associated or related. This special prioritization may prioritize therelated application layer over other enabled layers. Any file objectfound or created in the appropriate search is returned 1112.

This method may also be applied to registry settings, which method isinitiated by a request from an application a to perform a registryoperation. The process originating the request is identified, and if theprocess is associated to a layer, that layer is prioritized speciallyrelative to other enabled layers. A search of registry objects is thenperformed looking for an object corresponding to a registry key of therequest, using the determined priority. The results of the search aremuch the same as for file objects, but registry key values or referencesto registry objects may be accessed or returned instead.

In a related method depicted in FIG. 12, a close request 1200 maygenerate activity in the layered system. The open request may generate afile reference object, which may contain information about the filename,the position of the pointer in the file, permissions, and otherinformation. This object is released 1202 when the file is closed, andthe closing function may report the success or failure of the closeoperation 1204.

In the case that a process is associated with an application layer, thepriorities of evaluation of enabled layers can be advantageouslymodified. For reads, a layered system can prioritize the applicationlayer higher than other layers, and increase reliability. By doing so,it can be ensured that the application's libraries and other files willbe considered first before other libraries located to the base or otherlayers of unknown versions and origins. Likewise, an application layerrelated to a process that performs a write operation can be prioritizedhigher to ensure that those writes are retained with the applicationlayer. This association is good and logical when used in connectionwith, for example, configuration related to the application. The writingof user files apart from an application layer will be addressed below.

It is possible for the system to maintain more than one priority for anapplication layer. This can be used, for example, to cause writes ofuser files to appear in a layer other than the application's layer. Forexample, the application layer might be prioritized highly for reads,thus ensuring use of the libraries, configuration and other filessupplied with the application. But for writes, the application layergets a lower priority than another writable layer (or the basefilesystem), ensuring that user files remain accessible even if theapplication layer is disabled or removed from the system.

Different priorities can also be assigned for different types ofaccesses or activities. One example of this provides an improvement tothe automatic execution of applications based on a file type. In moderngraphical operating systems, a user can ‘launch’ a file rather than anapplication by double-clicking the application. For example, if a userdouble-clicks on a .htm file, the default web browser on the system willbe started with the file as an argument. A layered system can assign adifferent priority to lookups for this activity.

In a Windows operating system, associations of file types toapplications is by HKCR registry entries. Thus a file explorerapplication looks to these registry entries to see which applicationshould be started if a file is double-clicked on. These registry entriescan be provided in an application layer, and thus when such a layer isinstalled and enabled the application is used to open its assigned filetypes. But a question, however, arises if two applications are installedwhich can open a common file type. For example, most word processors canopen a plain text file. Many operating systems include a simple texteditor that can also open such a file. Without the assignment ofpriority between the application layers, one may take priority over theother at random, or due to some artifact of priority evaluation in thecomputing system.

In an alternative priority scheme, each application layer is assigned apriority for its file type associations. When the file type associationsare accessed (which may be HKCR registry entries) the application layersare examined in order of that priority for a matching file typeassociation. In this way, a layered system designer can control the setof preferred applications to open or process certain file types, and byassigning a priority for each application layer control the preferenceamong them. In a variation on this alternative, each file associationcan be assigned a priority, making possible different priorities forassociations in an application layer, permitting one application to bepreferred for one type and another application to be preferred for asecond. This scheme can also be extended for operations other thanopening files, for example selecting a preferred backup or compressionprogram based on a file type.

The concepts mentioned above can be brought together in a singlelayering system to provide tailored operation for particular needs.Illustrated in FIG. 7 is one such system. The layering scheme of FIG. 7is based on an ordinary operating system, which includes a base filesystem 700 used by the operating system by default. Base file system 700includes the necessary files to bootstrap the operating system andundertake ordinary operating system actions and activities. Base filesystem 700 may simply reflect a common operating system installation toan ordinary computing device. The scheme of FIG. 7 prioritizesapplication layers and other layers installed to the computing systemconceptually as shown, with vertical relationships generally reflectinga layer dependency.

In the example of FIG. 7, an application layer 702 is installed to thecomputing system. Application layer 702 is configured as read-only, andcontains the application files that would be installed to the base filesystem 700, but captured to the layer, such as the executables, helpfiles, configuration, libraries and other application files. Applicationlayer further includes a read-write sublayer 704 associated to layer702, which may store changes to the application configuration, add-onsand other files. A data layer 708 is a read-write layer used to storeuser files generally or for a particular user. The other layers areconfigured read-only to prevent inadvertent or malicious changes. Layer710 contains a patch to the operating system. The files included inlayer 710 might be updated libraries and system applications withadditional functionality. It might also encapsulate a service pack orupdate, providing updated operating system files with a number ofproblem fixes. Security patch layer 712 contains a security patch, whichmay be only an updated version of a single operating system file to fixa hole or exploit existing in a prior version. Also incorporated to thecomputing system is an application patch 714, which provides updated orfixed versions of files located to application layer 702 in either theread-only portion or the read-write sublayer.

In the priority scheme of FIG. 7, all the layers are identified by oneof the types shown, for example by a fixed label included with thelayer. The layered computing system identifies the layers by theirtypes, and applies the priority scheme in automated fashion. First,consider the priority for read operations. The layers with highest readpriority in this example are the security patches, such as layer 712.This is advantageous to system administrators because if the layer ispresent on a computing system, the security fixes contained therein aresure to overwrite any flawed files an attacker might use to gain controlof the system. The next priority for reads is the application patchlayer 714. Patch layer 714 must be considered before application layer702 to override any older files distributed in that layer. Patch layer714 may also override read-write sublayer 704, although care may beneeded not to override any local configuration stored thereto. Theread/write sublayer 704 gets next highest priority to ensure that anylocal configuration written thereto overrides the default configurationstored to the read-only layer 702. The application layer 702 isprioritized over the base file system 700 and any operating system patchlayers 710 to ensure that an application can override the defaultbehavior of the operating system, for example to place an icon on thedesktop or to provide a shared library that is newer or provides morefunctions than the default. Of course, any operating system patch layer710 precedes the base file system to override older files. Read-writabledata layer 708 can be prioritized in many ways into this scheme,generally in accordance with the control the user is to be given overthe computing system. For example, data layer might be prioritized justabove the base file system 700 to preserve the base file system in apristine state that can be reverted back. Such a data layer may providefor simplified backups of user data, as the backup program (which couldmerely be an export of the data layer) need only backup the contents ofthe layer. A data layer might be prioritized last for writes, as acatch-basin for miscellaneous files not landing in another layer or thebase. If a user is a developer, it may be desirable to have a data layerthat overrides all other layers so new files can be tested withoutre-building existing layers.

In the scheme of FIG. 7, an application layer can be prioritized higherthan other application layers if a read or write request originates froma process executing from that layer, if desired. It can also be seenthat the priority in that scheme differs between reads and writes,particularly for data layer 708. Now the priority scheme described andillustrated for FIG. 7 is not the only or the best priority schemepossible, but is merely one conceptual example.

For example, in other schemes a base filesystem may be treated as alayer. Thus if a process is not related to an application layer, thesystem may attribute that process to the base filesystem “layer”. Inthat case, libraries and other files in the base filesystem may takepriority over others contained in application layers or elsewhere.

Layer Specified Priorities

In the above examples, the layered computing system determines priorityfrom the identity of the enabled layers. Thus, each layer carries anidentifier of some sort useful to the layered system drivers todiscriminate between layer types. In alternate schemes, a layer mayspecify where it fits in the priority scheme.

In one example, a layer may carry information that instructs the layeredsystem to prioritize the layer before (or after) other identified layersor base filesystems. Thus an operating system patch may instruct to beinstalled above the base filesystem, but below other application layers.

In an alternative, layers can carry priority values or weights relativeto other layers, or base filesystem(s). In one example, values arerepresented as floating point values between 1.0 and 100.0, where lowernumbers are higher priority. As new layers are defined, these can beprioritized between other layers. So in a system where a security updatecarries a priority of 30.0, and an application layer of version 1.0 ofan application carries a priority of 50.0, an application layercontaining version 2.0 of the application might be prioritized anywherebetween 30.000 . . . 1 and 49.999 . . . . The exemplary implementationbelow is such a system, and the use of values assigned to layers willbecome more apparent from the description below.

A weight may be identified for each enabled layer, which determines thepriority of searches for objects in the enabled layers. A default weightmay be applied to a layer, depending on the layer type. A layer may alsospecify weights relative to a base filesystem or to other layers. Morethan one set of weights may be used for searches of differing types. Insome layered systems, accesses to file type associations, for examplecontained in a registry, may take on a special priority. In one example,in a system that has file type associations to applications, a secondset of weights may be used to provide for associative priorities betweenapplications handling the same files, where those priorities may differfrom ordinary file accesses. The file type association or registrysetting appropriate to that differing priority is returned or accessed.A layer may carry other additional weights, for example a weight to beapplied to a layer associated to a requesting process, or a differentweight for a write operation. Thus a default weight may be applied,overridden by weights for associated processes, file type associationrequests or other factors, thus applying a different layerprioritization to the layers as a whole for requests from differentprocesses or under special circumstances.

Exclusions and Inclusions

In one preferred system, layering only applies to files located to fixeddisks and network drives, each layer spanning one or more fixed disks.In that system removable disks should not generally be layered, as alayer generally pertains to the persistent files and configurationrequired to operate an application or user environment. It is expectedthat under most circumstances user files should be permitted to be savedto a floppy disk or CD-RW, for example, so a user can transport his datafiles to another computer. Likewise, areas on a fixed disk may also bereserved for user or other files to be excluded from layering, forexample a “my documents” directory, as desired.

One way of achieving this is through the use of layers that carry filereference information, specifying what files may (or may not) be writtenthereto. Thus, as a write request is received, the file reference of therequest is compared against the file layer information which determineswhether the write operation is directed to that layer. The filereference information may take the form of inclusion or exclusionentries. Exclusion entries specify files and paths that are disallowedto be found in a layer, while inclusion entries are the opposite.Exclusion or inclusion entries may be defined for a file type, or for adirectory or path.

Exclusion entries define file types or paths that may not be written toa layer. When applied to an application layer, exclusion entries mayprovide control for the application provider as to what will land in (bewritten to) the layer. For example, it may be that the application layerprovider wishes to capture only certain file types corresponding toconfiguration, but not to user files, in order to ensure that theapplication layer does not need to be backed up, or to ensure that theapplication layer provider is not responsible for user data loss. Thismay be done by entering exclusion entries in the application layerinformation for the user file types and directories. Inclusion entriesmay also be used, which entries indicate file types and paths that areto land in the layer. So in the example, inclusion entries might permitapplication configuration file types and the application's installationdirectory.

Inclusion and exclusion entries may also be used with data or userlayers, which may be configured to capture user file writes that wouldotherwise land on a base filesystem or in another layer. Data and userlayers may also be prioritized accordingly to make effective theirexclusion or inclusion entries. For example, a data layer containinginclusion or exclusion entries may be prioritized before any read-writeapplication layers or sublayers to capture the specified files, avoidingdeposition into the application layers. Alternatively, an applicationlayer may contain inclusion or exclusion entries, and when coupled witha lower-prioritized data layer permits certain files to be written tothe application layer while preventing other writes from landing on abase filesystem.

Automated Enablement/Disablement

Some systems may provide a multi-user environment providing a facilityfor an administrator to designate layers accessible to individual usersand another facility to automatically enable layers on user login anddisable layers after a user has logged off. In those systems anadministrator may provide layers accessible to all users or some users.Other layers may be provided accessible only to an individual user. In asubset of those systems a writable layer is provided for each user,providing data protection and isolation between users.

It may also be desirable to provide a startup layer enablement function,whereby the computing system starts up a group of layers based on layerconfiguration. This will be especially helpful where it is desired notto provide users with non-layered access to the underlying file systemand registry, for example in public settings.

Process and File Operation Handling

In a layered computing system supporting application layers, it can bedesirable to relate processes to application layers. In the example ofFIG. 7 processes were related to application layers to determinepriority between layers. It may also be useful to track processes forpermissions to access layers or the base filesystem, for example in asecure layered system. It is therefore worth considering a processlifespan in the layered computing system.

A multitasking computing system maintains a number of tasks running atthe same time, which are referred to as processes. Relatedly, a singleprocess can develop several sub-tasks which are sometimes referred to asthreads. In the systems discussed here, processes are the tasks trackedby the operating system, thus permitting differing treatment for fileaccesses between them. A system discriminating between threads isconceivable, given appropriate inter-process or inter-kernelcommunication.

In modern operating systems, the computer is booted into a masterprocess which exists until the system is shut down. As the system boots,new processes are created to handle the numerous tasks handled, whichare as diverse as email handling to handling timer events. One of theseprocesses is a shell or graphical user interface providing reception ofuser input. As a user logs in, new processes are created for the userwhich may be run with a restricted permissions set. As a userdouble-clicks on icons or selects menu options, new applications can bestarted, which applications run by the execution of one or moreprocesses.

At the most basic level, a new process is started using a “fork”procedure. The reason it is called a fork is because one process isturned into two, which are the parent process and the child process.When a process is complete, it “terminates” and the operating systemceases to multitask time to it and releases its memory. Furtherdescription of the intricacies of process creation and termination willnot be necessary to one of ordinary skill in the art for the remainderof this discussion.

One technique of process tracking involves watching the forks andterminates on a computing system. This can be done by inserting customfork and “kill” or “signal” functions, for example by vectorredirection. Now turning to FIG. 9, a fork process is illustrated thatis capable of creating associations between processes and layers. A forkrequest 900 is made from an existing process, for example by callingfork( ) or by another method effective to request creation of a childprocess. At this point, a new process is created 901, and the new childprocess is assigned a new process ID (or PID) which appears to thekernel's process management data structures. In the course of creating anew process 901, the parent process will return from the fork( ) call,typically with the process ID of the new child. The remaining stepsshown are performed by or for the child process rather than the parent.

Next, the method attempts 902 to identify any application layerassociated with the parent process. If an application layer isidentified 904, the method proceeds to relate the child process to theparent's application layer. In the method shown, an exception 906 ispermitted to avoid this assignment. This is useful, for example, wherethe system can determine that the process being created is a systemprocess, or a process that should execute from a different applicationlayer. If there is no exception, the child process may be associated tothe parent's application layer 908. If there is an exception, the methodconsiders whether another layer should be assigned in step 912.

Referring back to step 904, if a layer is not associated with the parentprocess, the method considers an exception in step 910. This exceptionis triggered where the system can determine that an association isappropriate. For example, the fork request may originate from an exec( )call (discussed below) and may be executing a file within an applicationlayer. If there is an exception, the child process is assigned 914 to alayer as appropriate. If an exception occurs in steps 906 or 910, theprocess considers 912 whether the new process should be assigned to alayer. This might be appropriate where a system is being run in a securemode, where all new processes are assigned to some layer to capturewrites, such as an intrusion protected layered system, or in a systemthat requires assignment of a layer for all processes. If a layer is tobe assigned, that is done in step 914, which may optionally create a newlayer if necessary. If no layer association is determined otherwise, thechild process remains unassigned in step 916. Finally, the child processis permitted to return from the fork( ) call and begin process-spaceexecution.

Now it is to be understood that processes can be reassigned as they arerunning, and the associations determined in the method of FIG. 9 or atprocess creation need not be permanent. In an alternate method, theexceptions determined in steps 906, 910 or 912 can be made afterobserving the behavior of the child process. For example, if the processopens a file type permitted only by system processes, it may beappropriate to remove the assignment to an application layer (orassociate the process with the base filesystem(s).) In the exemplaryimplementation described below, an association is made to a systeminstallation process if access of an installation file is made.Alternatively, if a process attempts to write to system directories in asuspicious manner, a new read-write layer can be created for the processand an association made.

In one example of exception handling, a layered system may be made torecognize installation processes that attempt to install files that arepart of an application contained in an application layer. Someapplications permit parts to be installed at run-time. These includebrowsers that install plug-ins, or applications that check for andinstall application updates. Some operating systems provide a systeminstallation service usable by applications through inter-processcommunication commanding certain installation actions. This serviceprocess may not be associated to any layer, and thus if it performsinstallation activities for an application those installation parts maynot be recorded in the appropriate application layer.

In the course of installation, a file of the application may be accessedto obtain installation configuration. In the example, as a file isopened within a layer, a determination is made as to whether therequesting process is an installer process. If so, that process isassociated to the layer to which the file open request is found in. Adetermination may be made, in some cases, through a recognition that afile is being opened that is an installer file. An installer file, forexample, might have a particular name or extension. Another methodexamines the requesting process, and recognizes it as an installationprocess if it was executed from an installer executable. This may bedone, for example, by comparing the name of the executable against knowninstaller executable filenames. Of course, both may also be used. Insome systems, the installer process will keep the installerconfiguration file open during the install process. In that case, theinstaller process may be released from the association to theapplication layer at the time the installer file is closed.

A companion function to the fork function is the exec function. The execfunction is called with an argument of a file to be executed in thecreation of a new process. The process shown for FIG. 9 can be appliedmore specifically to an exec call. For example, in determining anexception 910, the filename passed to exec can be opened, and in theprocess of performing a priority search the containing layer can beidentified. This may be done by detecting requests to open and execute afile object, creating a new process, and associating the process withthe layer in which the file object is found, if any. Thus applicationsexecuted from other application layers can take on the priorities of theapplication layer in which they reside. On the other hand, indetermining an exception 906 or 912, the pathname passed to exec can bereviewed for special treatment for certain filename extensions ordirectories. Alternatively, the new process may be associated with alayer associated to the requesting process.

Now regardless of whether in a particular operating system functionsnamed fork and exec exist, all multitasking operating systems will carryequivalent functions for creating new processes as described above; thisdisclosure is inclusive of any such operating systems, and thoseequivalent functions are included within the meaning of fork and exec.

Tracking of processes may be as simple as a table containing entries foreach associated process in combination with a unique layer identifierfor each. For simple priority schemes, this can be expected to worksufficiently well. For more sophisticated priority schemes, it may bedesirable to build a record local to a layered driver containingpriority information for each process, alleviating overhead processingthat might be encountered for processes that frequently access files.Overhead may not be significant, however, because priority searches needbe done only as files are opened, which is a relatively infrequent eventin many computing systems.

In the case where processes are tracked in a table as described abovewithout a local record, closing a file results in merely removing theprocess entry from the table. If a local record is kept, a process maybe used as depicted in FIG. 10. As a process is terminated 1000, theprocess first determines whether the terminating process is assigned toa layer 1002. This may be done by reviewing the tables, records, orother data structures maintained for process association tracking. Ifthe process is assigned to a layer, the layer is disassociated from theprocess 1004. In the method of FIG. 10, local association structures maybe shared between processes, as the priorities between processesassociated with the same application layer may be the same. A furtherdetermination is made in step 1006 as to whether other processes areassociated to the layer the terminating process was associated to, andif not, the priority record is released from memory 1008. If otherprocesses are associated to that layer, the layer priority record ispreserved. Finally, the process is terminated and any records for thatprocess are released 1010.

Apart from the process to application layer handling, the operation withrespect to file operations of an exemplary layered computing system isconceptually depicted in FIG. 6. Activities occur in three spaces: theprocess space 600, during execution of processes; the system space 604where basic operations occur at the operating system level; and the FSLspace 602, in which operations are performed by the layered file systemdrivers between the process and system spaces. The file operations aredivided between two groups, which are operations that require prioritytreatment and those that do not.

Operations 610 that require priority treatment include open( ). Stat( )will typically require priority treatment because the file informationreported by stat( ) will be specific to a file object potentially inmore than one layer. Other file functions, such as opendir( ) forobtaining directory listings, are also included in this functionalgroup, and are explained in detail in connection with virtualization.

When a file function 610 is called that requires prioritizationtreatment, the arguments are passed to a function in the FSL space 602.This can be done by redirection of the default system functions foropen( ), stat( ) and like functions into the layered system driver. Thefirst step performed in the FSL space 602 is variablization processing,which is explained more fully in the discussion of FIG. 8. A prioritysearch is then conducted 614 to identify the layer or base file systemthat contains (or will contain for writes) the requested file. It isconvenient at the same time to apply directory hiding, if layers arestored in directory structures on a base filesystem, preventingunauthorized or unintentional changes and confusion on the part of auser.

For stat( ), if the file object is located in a regular filesystem, thesystem stat( ) call can be used to get and return the appropriate data.For an open call, and upon locating a corresponding file in a layer orbase filesystem (or for writes, locating the layer or base file systemwhere the modifications will be recorded), the ordinary system open( )may be called. At this point, there are two possibilities. The first isthat the file handle returned by the system open( ) can be returned tothe calling process. This may be the case where the returned file objectexists as a file on a base filesystem that the operating system canread. This is the case represented in FIG. 6 by the use of the filesystem calls in space 604. In an alternative, layer contents can bestored within a larger file, as blocks on a storage device, or as anetwork accessible file or data. In those cases, special file operationsfunctions can be crafted which operate in the place of the regular filesystem calls.

The second possibility also comes into play in an alternative operation.It may be that the file object is not stored in the same form asutilized by programs, for example if the file is compressed or encryptedby the layering system. In that case, inter-file processing needs to bedone. That step, 618, is performed following the opening of the fileobject, which might be a lookup of an encryption key or merely a flagindicating that further processing is to receive specified treatment. Ifsystem file handles cannot be returned back to the originating process,the method utilizes substitute or virtual file handles 620 which referto the virtual file objects.

The remaining file functions need no prioritization treatment, becauseprioritization has been applied using the open( ) call or another. Aread call 632 is passed to the FSL subsystem for inter-file processing640, if needed. The FSL subsystem makes any necessary reads 652, whichmight be system reads as described above. The same applies to writes363, which may also be inter-file processed 640 and utilize a writefunction 656, which again can be a system write( ) in some cases. Theinter-file processing may employ a buffer for an opened file if thespecified processing so requires. For example, a compressed file mayhave been compressed with a particular block or window size, and thusprocessing 640 will maintain a buffer the size of that block or windowplus the standard block size for files on the operating system. Calls toclose 634 also pass through the inter-file processing, so as to permitany final processing to occur before file object is dereferenced in afinal call to close 654.

Integration and Software Management Tools

A layering system may include tools to install, remove, and manage thelayers on it. Although there are many ways of managing layers, and thusthe application layers installed on a computer, a few are described hereas examples.

In the first example, the layering system software is installed as adriver that intercepts system filesystem calls. The driver includes aninterface for receiving commands to enable, disable, and perform otheroperations as desired, for example by defining a set of system calls. Inthat example, a custom application may be constructed that interfacesdirectly with the driver to command layer operations.

In a second example, a library is provided that defines an applicationprogrammer interface. Rather than using an application that interfacesdirectly with the driver, the library API is used. This facilitates thedevelopment of a manager application and other applications that requireaccess to the layering system controls.

A manager application might be a textual application run from a shell,or it might be a graphical application that runs in a window. In theexemplary implementation below, the manager application is run from theshell, permitting remote applications control through the use of networkprotocols such as telnet or secure shell. In an alternative, a systemmay include an agent that supports custom access through a network, suchas through the Windows Management Instrumentation (WMI) interface andprotocol.

Additionally, a management tool can be made a component of a largerclient computer management tool. This can be useful where a number ofclient computers are to be managed remotely, controlling the applicationsoftware installed thereon through the layering system. The exemplaryimplementation below is one example of such a system.

Manager Application

For ease of configuring and managing a layering system, a managerapplication may be provided. The manager application permits anadministrator or user to control the presentation of applications anddata on a system, as well as other functions. A manager application mayhave facilities for importing and exporting layers, using a standardlayer archive format. That archive format will advantageously becompressed, and may use standard archiving formats, for example thoseused by ‘zip’ or ‘tar’ type applications. A manager application providesa logical place to contain a facility for changing layered systemsoftware settings. A manager application might provide a viewer to viewinformation about a layer. Likewise, a layer editor may be provided toedit certain layer information as desired. An editor might also beprovided whereby registry settings and files can be added, removed, orchanged in a layer. A facility for selecting, enabling, and disablinglayers and layer groups may also be provided. Likewise, a facility fordefining and editing layer groups may be included, as well as layerdependency information. A facility for deleting and installing layersmay also be provided in that manager application. That application mayalso include an interface to cause layered system software to enter andexit capture modes.

A manager application may include an executable runnable from a shell orin a graphical user interface. Through that executable commands may bereceived whereby layers may be enabled, disabled, imported or otherwisecontrolled. A manager application may also include a network agentproviding for control, access and the receipt of commands by networkservers and other node types. A manager application may report the setof installed layers, and may also provide a report to a networkrequester which may be especially useful for remote applicationmanagement. A manager application may also include a network facility toreceive layers from a host, and optionally to remotely install thoselayers to the local computer.

Exemplary Implementation

The exemplary implementation is intended for a Microsoft Windows 2000,ME, XP or the like. Adaptations can be made for other versions of thoseoperating systems, or to entirely different operating systems as will beunderstood by one of ordinary skill. In the exemplary implementation,application layers as described above are called Virtual SoftwarePackages (VSPs), and exported layers are called Virtual SoftwareArchives (VSAs).

The architecture of the exemplary implementation is conceptuallyillustrated in FIG. 3. The architecture relies on one of the operatingsystems 314 noted above, which includes a registry subsystem 316 and afile system subsystem 318 for accessing and handling files. Installed tothe operating system is an FSL system driver 312, which in the exemplaryimplementation is named “FSLX.SYS” and may reside in thesystem32/drivers directory of the Windows directory. That driverincludes functions to replace the ordinary file system calls such asopen, read, write, etc., other functions needed to manage layers in anenabled state, and functions for determining priorities.

A Windows explorer application 302, which is the usual application forreviewing and opening the contents of base filesystems, makes calls tothe FSL driver 312 through the redirected file system calls, which makesenabled layers visible to the user. Other applications 304 can accessthe layers the same way through FSL driver 312.

An FSL management application 300 is provided in the exemplaryimplementation, which is named “SVScmd.exe”. This application relies onFSL API library 306, which is named “FSLLIB32.DLL” and may reside underthe Windows/system32 directory. Library 306 contains functions thatimplement an API to control operations to the FSL driver 312, includingthe following operations: activate layer, deactivate layer, importlayer, export layer, rename layer, enumerate file/registry data andedit, enumerate/manage layers, view/edit layer properties, resetread-write layer or sublayer. A compression library 310 or applicationis included for exporting compressed VSAs and importing the same.

The SVScmd utility supports a number of commands as arguments, which areA[CTUVATE], D[EACTIVATE], R[ESET], I[MPORT], E[XPORT], DEL[ETE],REN[AME], C[APTURE], AUTO[ACTIVATE], P[ROPERTIES], CREATE, VER[SION],ENUM[ERATE LAYERS], SEND [INVENTORY], H[ELP], SET [KEY], CHECKKEY(checking and displaying information about a product key), PRIORITY(adjusts a layer's priority settings) and EXEC [FROM LAYER] (Makes theprocess specified as running from the layer).

The exemplary implementation is controllable from the Real-Tirne SystemManager Solution of Altiris of Lindon, Utah. Support is provided forthat by a WMI agent, which provides much the same API access as theSVScmd program. The agent includes a DLL library and MOF file, bothentitled AltirisVSProvider. The exemplary implementation includes asecondary manager application for network-management named SVSAdmin.exe,and also includes an FSIUI.DLL library and supporting language files. Inthe above management tools, a product key is required to successfullyperform the requested layer control operations. The tools further definea set of administrators as a group that can perform layered operations,which may originally be the set of users with administrator privilegeson client computers. It is to be recognized that another system could befashioned without such limitations if desired.

The exemplary implementation supports variablization, and includes twosets of variables. The first set of variables are defined as the layeredsystem boots. The second set is defined at the time of user login. Theboot variables include %SYSTEMDRIVE% (the drive letter of the drive fromwhich the operating system was booted) and %WINDIR% (the directory ofthe “windows” directory, which is sometimes “C:\Windows” or “C:\WinNT”.)The user variables include settings such as %DESKTOP% (the desktopdirectory of the user, which might be C:\Documents andSettings\User\Desktop) and %USERPROFILE% (the profile directory of theuser, which might be C:\Documents and Settings\User), and other settingssuch as the path to the “My Documents” directories and the like.Variables are stored by the layering system drivers, and in theexemplary implementation are made accessible to user processes andapplications through environment variables.

In the exemplary implementation, certain tags are stored in paths inlayers for variablization. “[_B_]” denotes the beginning of a variablename, and “[_E_]” denotes the end. “[_CS_]” is used to instruct atranslation to a short path representation. A short path is a path thatfollows the older 8.3 filename convention (i.e. eight charactersfollowed by a period followed by three characters.) A short path isdeterminable usually by the presence of a tilde character, which someolder programs may use particularly in the registry. “[_MSI_]” instructsa translation to an installation path (by replacing a colon in an MSIpath with a “?”). Other tags may be defined to further translate pathsas needed.

In encoding virtual paths to variablized paths for storage as a file orregistry reference in a layer, there may be some to which more than onevariable would apply. In that case, the exemplary implementation favorslonger variables over shorter ones, where longer means that moredirectories levels are included. For example, C:\Documents andSettings\User\Desktop\1.txt would convert to %DESKTOP%\\1.txt and not%USERPROFILE%\Desktop\1.txt.

Not only may file paths variablized, but other settings as well.Registry settings that specify paths can be variablized. For example, anapplication might specify working or temporary directories, stored inregistry settings. Variablizing the registry settings permits theapplication to be more portable. For layers that include exclusion orinclusion entries, these may also be variablized. For example, a datalayer might contain an inclusion entry directing all writes toC:\Windows to the layer, thus protecting the system. The entry is betterdefined as a variablized path %WINDIR%, permitting the data layer to betransferred to another computer with a different Windows directory, forexample C:\WinNT or D:\Windows. Data layer inclusion and exclusionentries and MSI paths may also be variablized.

The exemplary implementation stores layer file objects in a directorystructure on a base filesystem, which is normally C:. The path to eachlayer's contents is %systemdrive%\fslrdr\#, where # is the uniqueidentifier of the layer. Virtual paths with variables included arestored with the variables embedded in the true paths. For example, on acomputer having one partition, the file “C:\Program Files\App\app.exe”would be stored as“C:\fslrdr\AppLayer\[_B_]PROGRAMFILE[_E_]\App\app.exe”. Files residingvirtually on a non-system drive (i.e. other than %systemdrive%) may bestored under a directory including a drive letter. Thus the file“D:\userfile.txt” might be stored under“C:\fsldr\DataLayer\[_DRIVED_]\userfile.txt”.

In the exemplary implementation, layer information is stored in thesystem registry under the HKLM\SYSTEM\Altiris\FSL\# prefix, where # isreplaced by the unique identifier of the layer. Alternatively, foroperating systems without a system-wide registry, a registry or similarstructure can be maintained by the layering drivers or other software.Each layer includes the following fields:

Key Value ActivateTime Last time the layer was activated Active 0 =inactive, 1 = active ActiveOnStart 1 if layer should be activated onsystem startup CreateTime Layer's time of creation Enabled Deprecatedentry FileRedirect Path to the file redirection area ID GUID thatidentifies this layer (required to be unique) MajorVersion indicateslayer format MinorVersion indicates layer format Name A name for thislayer that is not required to be unique PeerID ID of companion sublayerReadOnly 1 = readonly sublayer, 0 = readwrite sublayer RefreshTime Timethat the layer was last reset RegRedirect Location in the registry forlayer registry data Type 0 = RO, 1 = RW, 2 = Data ShouldDelete 1indicates that the layer is to be lazily deleted (optional)

In the exemplary implementation, just as virtual files in layers arestored in a directory structure on a base filesystem, virtual registrysettings are stored in the system registry. Registry settings are alsostored under the HKLM\SYSTEM\fslrdr\# prefix in the system registry.Layered registry entries need not be stored in a VSP, rather thoseentries can remain in the system registry for a layer marked disabled.

Further in the exemplary implementation, the layer definitions furtherinclude SVS extensions for OnEvent Actions. These layer specific entriesare stored in the registry under HKLM\SYSTEM\Altiris\FSL# with otherlayer definition attributes, and may contain the entries ofOnPreActivate, OnPostActivate, OnPreDeactivate, OnPostDeactivate,OnPreImport, OnPostImport, OnPreExport, OnPostExport, OnPreReset,OnPostReset, OnPreDelete, OnPostDelete, OnPreCreate, OnPostCreate,OnPreCapture, and OnPostCapture. Also note that SVS also processes “run”entries in the layer's registry data and the files in the layer's“Startup” folders (for “user” and “all users”.) Global SVS entries arestored in HKLM\SYSTEM\Altiris\FSL. Entries may use the REG_MULTI_SZvalue type to store multiple actions for an event.

In the exemplary implementation, the root of the registry redirectionarea for each layer (HKLM\Software\FSL\#) contains representations offour registry root keys: HCC represents HKEY_CURRENT_CONFIG, HCUrepresents HKEY_CURRENT_USER, HLM represents HKEY_LOCAL_MACHINE, and HUrepresents HKEY_USERS. These keys contain the layer registry data thatis overlayed when the layer is active.

The registry also contains areas labeled “ControlSetxxx” where “xxx” isa number value (usually 001, 002, or 003). At any one time only one ofthese areas is “current”. The registry maintains a “pointer” towhichever controlset is being used. This is called “CurrentControlSet”.Any registry activity directed at CurrentControlSet is redirectedinternally by the registry to the appropriate ControlSetxxx that iscurrently in use. Any activity going to the layer directed either atCurrentControlSet or ControlSetxxx (which is the active set) isredirected to CurrentControlSet in the layer.

Likewise, the registry redirects activity from HKCU to its real locationHKEY_USER{userSID}. When activity is going to a layer, both of theseareas are redirected to HCU. This is done for portability.

Similar to this, HKCR is a pointer to data contained inHKCU\Software\Classes and HKLM\Software\Classes. HKCR can be opened,queried, etc. Just like a normal registry key, but the data is reallystored in these other locations. In a layer, the illusion of an HKCR keyis not maintained. Data to this area goes into its real locations in thelayer area. So, for example, if a create of a value was requested toHKCR and prioritization indicated the value was to go to a layer, itwould go to HKLM\Software\fslrdr\#\HCU\Software\Classes.

When a layer is imported, all the registry and layer settings describedabove are also imported to the system registry, where the FSL driver canaccess conveniently. When a layer is disabled, the driver maintainsthese layer settings in the registry until the layer is removed from thesystem.

The exemplary implementation also supports file deletion entries, whichare stored as a list of pathnames in %systemdrive%\fslrdr\#\DELLIST.TXT,where # is the layer ID. This is a unicode file, one entry per line. Theexemplary implementation expands short filenames, so long file names areused to specify delections. Entry paths are variablized.

Registry entries that are deleted are also stored in the layer registrydata in the system registry. A delete entry for a key is the key with˜FSL˜ prepended to the original key name (e.g. “˜FSL˜Altiris” would hide“Altiris”). A delete entry for a value is a value with ˜FSL˜ prependedto the original value name. A deletion key other than “˜FSL˜” can bechosen if desired, provided that the necessary changes are also made tothe layering driver software.

Exclude entries for files are also interpreted by the exemplaryimplementation, where they are entered under the subkey “Exclude”, wherethe value name is the file extension or path of the exclude and the datacontains the type. There are three types of entries, which are 0: fileextensions, 1: directory path, subdirectories not included, and 2:directory path, subdirectories included (paths are variablized.)

Data layers in the exemplary implementation are identified in theregistry with a “DataLayer” subkey. Entries can be made for a datalayerusing the same format as the exclude subkey entries. A data layer sodefined will capture all writes made that are not excluded.

In the exemplary implementation a VSP or layer can exist with one offour states. In a first state, deactivated or disabled, the layer existson the computing device, but the layer contents are not visible oraccessible to programs. Alternatively, in the enabled or activatedstate, the contents are visible and are made available for reading andpossibly changing by programs. Layers in one of those two states arereferred to as imported, because they are in a state of ready access anduse by the layering system. In the exemplary implementation this meansthat the layer's registry entries and other information exist in thesystem registry, and are accessible to the FSL driver.

In a third layered state called “exported”, the layer's file objects,registry settings and other information are encapsulated in a singleobject that can be transported. In that state a VSP becomes a VSA. Inthe exemplary implementation exported layers are encapsulated asarchives in the PkZip format. Any sublayer is encapsulated in asubdirectory, with an identifying #.layer text file (where # again isthe ID of the sublayer) containing the following entries: on line 1 isthe layer name, on line 2 is the layer GUID (i.e. Globally UniqueIDentifier), and on line 3 is the layer type (0:RO, 1=RW, 2=DATA). Theparent layer likewise has a #.layer file of the same format, where # isthe ID of the parent layer. For each layer and its sublayers, thecontents are stored in a directory as follows. First, all the fileobjects in each layer are stored in a directory structure within themain directory in relative position to the path the file object isstored against the target directory structure. Thus, for the exemplaryimplementation, the %systemdrive%\fslrd\# directory is simply copiedinto the archive. The DELLIST.TXT file containing file object deletionsis included there. The exemplary exported layer contains threeadditional files, which are “fslreg1” containing the layer definition(reflecting what was or wound be stored in the registry), “fslreg2”containing the registry data of the layer, and “OSVER.INI” containingversion information about the system that created the layer archive. Alayer may also optionally include files containing other information,such as the number of file objects, registry keys and values, filesystemspace used by the layer, or other information as desired.

Finally, a layer may be in a fourth state pending deletion. In theexemplary implementation, layers are not merely deleted, but are markedfor deletion first. The reason for this is two-fold. First, it may bethat other disk operations are active, and it may be desirable to removethe layer's file objects, registry settings and information from thecomputing system at a later time, in a “lazy deletion” fashion. Second,it may be that files are open contained in a layer or processes areexecuting from the layer. Deletion of the layer at that time could causean error, and therefore the exemplary implementation does notimmediately delete a layer if objects remain open therein. As files areclosed and processes terminated, the layered system software canre-evaluate whether it is prudent to remove the layer from the computingsystem. Alternatively, layer objects can be deleted at system startup orshutdown, particularly application layer objects that are unlikely to beneeded for those activities.

Prioritization in the exemplary implementation is done through assignedpriority values. The default priority values are as follows: a datalayer, 45.5; a normal process owner, 55.5; a base process owner, 65.5; abase filesystem, 75.5; and a normal layer, 85.5 (higher values indicatelesser priority.) The meaning of “owner” in this context differs fromprior uses; in this context a process owner layer means a determinationthat the file operation originates from a process related to orassociated with the layer. So if a process is related to an applicationlayer, that application layer will be assigned the normal process owner(“normal owner”) priority, while other application layers are assignedthe “normal layer” priority. Likewise, if a process is not related to alayer, it receives the base process owner (“base owner”) priority. Notethat for this prioritization, the base filesystems are counted as alayer and are not given special treatment. Also in this prioritization,note that should a .dll library exist in a non-owner layer and the base,the base takes priority under the presumption that that version is moretrustworthy to applications generally.

The exception to this prioritization is for HKCR entries, again whichregistry entries define the default applications that are used whenopening certain file types. If the layered drivers detect a read accessto an HKCR entry, the default priorities are modified as follows: anormal owner, 55.5; a normal layer, 65.5; a base filesystem owner, 75.5;and base filesystems, 85.5. This prioritizes enabled application layersover the base filesystem, which generally directs open events toinstalled applications rather than to applications stored in the base,and thus installed applications take priority over the base sodouble-clicking opens the layer-installed application.

In the exemplary implementation, each layer can be assigned priorityweights by an administrator or application provider over the defaultvalues, if desired. Four of these priorities are available for eachlayer. The first, called the “owner” priority, replaces the “normalowner” priority for that layer. Thus, when conducting a priority search,an application layer can be prioritized higher or lower than the normalor other layers. A second value defines the “normal” priority, whichreplaces the default “normal layer” priority above. By modifying thesevalues, a layer can be guided into a position of lesser or greaterpriority. For example, a newer version of an application layer may beassigned slightly higher priority than and older version, ensuring thatthe new version is seen over the old should both be enabled in thelayered system. The other two values are for HCKR registry entries,which are “HCKR owner” and “HCKR normal” and modify the default HCKRpriorities. Through modification of these values an application layercan be prioritized higher, if the contained application is morefavorably used than others for a given filetype, or lower, if theapplication is for only specialized use.

FIGS. 13A and 13B (hereinafter FIG. 13) conceptually illustrate aprioritization procedure used in the exemplary implementation, usingweighted prioritization values. A priority search 1300 is started foreach new file access or request to perform a file operation, which maybe opening a file or directory, or requesting file status orinformation. Each access or request generally includes a file referenceor path appropriate to a file system compatible with the operatingsystem. The method of FIG. 13 divides read accesses from write accessesin step 1302, and open for write requests are continued at step 1304.Other accesses follow the general procedure, which begins by anidentification of the active or enabled layers 1306 and construction ofa priority list 1308 as reflected by the default prioritization valuesand any genetic layer-configured values as described above. Thedetermination of priority for searching the enabled layers and basefilesystem(s) may also be performed by other than construction of alist. The priority list construction may reflect an HKCR read, and thususe the HKCR priorities. Next, the procedure considers 1310 whetherthere is an assigned layer to the process originating the file access.If the originating process is assigned, the priority list is adjusted1312 to reflect the “owner” default priorities and any layer assigned“owner” priorities.

Next, the layers are evaluated in order starting with the layer assignedthe highest priority 1314, searching for a corresponding file object. Iftwo or more layers have the same priority, they may be considered in anyorder with respect to each other. In step 1316, a search for a filereference matching the file operation is performed, which search alsoconsiders variablized names. Should a match not be found 1318, theprocess repeats for the layer having the next highest priority 1322until all layers have been considered 1320. Should all layers betraversed without a match, the procedure may report that a file was notfound 1324, report another appropriate message indicating that nocorresponding object could be accessed. Note that for some accesses,such as directory listings, all the layers should be traversed and step1318 is not performed.

Continuing for an open operation, after finding a match a file referencestructure is created in 1326. If the match was discovered in a basefilesystem, the structure will correspond to a base file object. For amatch to a layer, the structure will correspond to a virtual fileobject. The method then considers whether this access should be treatedspecially. In the method of FIG. 13, a trigger 1328 is made on a filetype, one example of which will be described presently. If the triggeris found, the system associates the running process with the layer thefile reference was discovered in. Finally, for open calls that read, afile reference is returned 1332 to the calling procedure, which may be abase or a virtual file handle.

The special treatment of steps 1328 and 1330 can provide improvedtreatment for application updates made through a standard installationprocess, such as the Microsoft Installer (MSI.) Through an installationprocess, an application may request a modular add-on installation,should the application discover that a module is needed by a user. Itmay be preferred that any add-on installation be captured to theapplication's layer, rather than appearing in the base or in anotherlayer. The MSI service, as with other services, operates as a systemprocess by inter-process communication. Thus when an applicationrequests a new installation, repair, or other installation activity, itsends a message to the MSI requesting the operation. As the MSI is asystem process running potentially from a base filesystem, that processis likely not assigned to a layer. Thus in a layering system that relieson process tracking only, those files installed by a service will not bedeposited to the application layer.

The exemplary implementation in step 1328 detects a read of an MSIpackage file, which accompany applications that may later install files.The MSI process is then assigned to the application layer in which theMSI installation file resides while the installation proceeds,specifically in the read-write sublayer of the application layer. Theassignment may be released at a later time as appropriate. This conceptcan be extended to other services that may deposit files on thecomputing system, such as a network service, logging service or printspooler.

For writes, the procedure set forth in FIG. 13B is followed. As forreads, active/enabled layers are identified 1340, and a priority listconstructed 1342 for those layers. The priority list constructed in 1342may omit layers configured to be read-only. A loop then proceeds todiscover the appropriate layer to which the write should be destined,starting from the layer having the highest priority 1344. This writeprocedure differs in that it considers exclusion and/or inclusionentries in layer definitions. First the layers are traversed for a layerthat specifies inclusion of the file, 1346, 1347 and 1348. If no layerspecifies inclusion, the method starts again with the layer of highestpriority 1350 looking at exclusion entries. If a layer does not specifyexclusion 1352 and is a read-write layer 1354, the destination isconsidered to be found. The layers are traversed in priority 1356 and1357 until either a layer is found, and if no layer is found to whichthe write operation may be directed, the process may either fail 1358 orcreate a new read-write layer for the write operation. If a destinationlayer is found, the write operation is directed to the currentlyselected layer 1360. A file reference structure is created 1362 and areference returned to the calling process 1364, which may be a virtualor base file handle.

For example, a layer A contains a.exe and c:\windows\common.dll. A basefilesystem contains b.exe and c:\windows\common.dll. Layer A isactivated and a.exe is launched (a.exe process' owner layer is layer A.)Layer B is then activated. a.exe does a file open operation forc:\windows\common.dll. For prioritization, the driver first assignslayer A a priority of 55.5 as the normal owner. Layer B is assigned apriority of 85.5 as a “normal” layer. The base is assigned a priority of75.5. The search order is layer A, the base, and finally layer B. Aslayer A contains the requested file, the access is directed to layer A.

b.exe is launched (b.exe process' owner layer is the base.) b.exe does afile open operation for c:\windows\common.dll. Layer A has a priority of85.5 (as a “normal” layer), Layer B a priority of 85.5 (also a “normal”layer), and the base is assigned a priority of 65.5. The base takeshigher priority, and the dll is delivered from the base.

In another example, a Firefox application layer is created with theproper registry entries in HKCR so that Firefox is registered to handlehtml files. The layer maintains the default HKCR priority. A secondOpera application layer is also created having a HKCR registry entriesmaking Opera registered to handle html files. The Opera layer is setwith an HKCR priority of 65.4.

First, the Firefox layer is activated, and the user double clicks a htmlfile on the desktop. The explorer goes to the registry to determine whatprogram handles html files. The layered driver assigns the Firefox layera priority of 65.5, and the base a priority of 85.5. Finding an HKCRentry for html files in the Firefox layer, the system directs thatFirefox.exe is launched for the html file and the base need not besearched.

The Opera layer is then activated, with the Firefox layer still enabled.The user double clicks a html file on the desktop. Explorer again goesto the registry to determine what program handles html files. TheFirefox layer takes a priority of 65.5. The Opera layer specifies apriority of 65.4. The base a default priority of 85.5. The search orderis determined to be the Opera layer, Firefox layer, and then the base.As the Opera layer has an HKCR entry for HTML files, the open request isdirected through it's HKCR entry to the opera.exe file in the Operalayer.

The exemplary implementation also provides for handling of services thatmay be provided in layers. Service definitions may exist in multiplelayers and the base. The control data of services are stored in a subkey“services” to the read-only layer definition of an application layer inthe registry. The data for a service is stored in a key named“FSL_{service name}”. Other keys named for the service includePreActivate, PostActivate, PreDeactivate and PostDeactivate. Each ofthese keys may contain subkeys from 1 to 4 which proceed in increasingorder. Each numbered subkey contains a command and a service name. Thenumbered subkeys take the following meanings: 1-create service(registers the service with the Service Control Manager, SCM), 2-startservice, 3-stop service, and 4-delete service (unregisters the servicewith the SCM).

Furthermore, the exemplary implementation delays deactivating a layercontaining a service entry until all the declared services complete orterminate. However, if a service is declared in two layers, the serviceis not stopped until the last layer declaring it is deactivated. Forthis purpose, reference counts are maintained in the system registryunder HKLM\SYSTEM\Altiris\FSL\Services.

Finally, for the exemplary implementation, layers may at certain timesbe required to disable, for example at system shutdown or if commandedby a management application. In that case, applications are attempted tobe terminated gracefully. When a layer is forced to be disabled, thelayered system sends a terminate signal to all associated processes, andwaits for those processes to terminate before disabling the layer. Thelayered system may also wait for open files directed to the disablinglayer to be closed before disabling the layer, or it may alternativelydisallow further opens to the layer and permit the running applicationsto continue to access their open files. If a user does not respond toapplication queries (i.e. “do you want to save this file?) the systemcan become locked pending user action.

The AutoClose function can prevent this lock-up. Stored in the registryare two global entries under the keys “AutoCloseApps” and“AutoCloseTimeout” under HKLM\SYSTEM\Altris\FSL. The “AutoCloseApps”controls whether applications are terminated automatically on layerdeactivation, and may be set to 1 by default. The AutoCloseTimeout valuedetermines the number in seconds to wait if AutoClose is on for a layer,for example 30 seconds. The global entries can be overridden by entriesof the same keys in the layer definition in HKLM\SYSTEM\Altiris\FSL\#.

While the present systems, products and methods have been described andillustrated in conjunction with a number of specific configurations,those skilled in the art will appreciate that variations andmodifications may be made without departing from the principles hereinillustrated, described, and claimed. The present invention, as definedby the appended claims, may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. Theconfigurations described herein are to be considered in all respects asonly illustrative, and not restrictive. All changes which come withinthe meaning and range of equivalency of the claims are to be embracedwithin their scope.

1. A layered computing system for accessing files in a base filesystem,said system comprising: a processor; a data and program storageaccessible by said processor, said storage comprising one or more datastorage devices; an operating system stored to said storage; computerreadable instructions located to said storage, wherein said instructionsare executable by said processor to perform functions of: receiving froman application a request to perform a file operation, the requestcontaining a file reference appropriate to the base filesystem,identifying a plurality of enabled layers and, for each of the enabledlayers, identifying a priority weight, determining a priority forsearching the enabled layers and the base filesystem, the priority basedupon each of the priority weights, performing a search for a file objectcorresponding to the file reference, the search performed in an orderdetermined by the priority, if, in performing the ordered search, thefile object is found corresponding to the file reference in one of theenabled layers, returning a virtual file handle to the file object, andif, in performing the ordered search, the file object is foundcorresponding to the file reference in the base filesystem, returning abase file handle to the file object.
 2. A layered computing systemaccording to claim 1 wherein each of the priority weights includes asecond priority weight, and wherein the second priority weight is usedfor prioritizing a request to retrieve an application association for afile type.
 3. A layered computing system according to claim 1, whereineach of the priority weights includes a normal process owner weight, andwherein if one of the enabled layers is associated to a requestingprocess, the one of the enabled layers is prioritized according to thenormal process owner weight.
 4. A layered computing system according toclaim 1 wherein said instructions are executable by the processor tofurther perform the functions of: for the requests for the fileoperations originating from processes not associated to the enabledlayers, assigning a default weight to each of the enabled layers and thebase filesystem, for the requests for the file operations originatingfrom processes associated to a one of the enabled layers, assigning aprocess owner priority weight to the one of the enabled layers,assigning the default weight to a remaining number of enabled layers notassociated with the originating process, and assigning the defaultweight to the base filesystem, and for requests to retrieve anapplication association for a file type, prioritizing each of theenabled layers according to an application association priority weight.5. A layered computing system according to claim 1, wherein the priorityfor write operations are different than the priority for readoperations.
 6. A layered computing system according to claim 1, whereinsaid instructions are executable by the processor to further perform thefunctions of omitting enabled layers configured to be read-only from theordered search for the file object.
 7. A set of computer readable mediacontaining computer instructions for accessing files in a basefilesystem, the set of computer readable media comprising at least onemedium upon which is stored the computer instructions executable by acomputing system to perform functions of: receiving from an applicationa request to perform a file operation, the request containing a filereference appropriate to the base filesystem, identifying a plurality ofenabled layers and, for each of the enabled layers, identifying apriority weight, determining a priority for searching the enabled layersand the base filesystem, the priority based upon each of the priorityweights, performing a search for a file object corresponding to the filereference, the search performed in an order determined by the priority,if, in performing the ordered search, the file object is foundcorresponding to the file reference in one of the enabled layers,returning a virtual file handle to the file object, and if, inperforming the ordered search, the file object is found corresponding tothe file reference in the base filesystem, returning a base file handleto the file object.
 8. A set of computer readable media according toclaim 7, wherein said instructions are executable by the computingsystem to further perform the functions of utilizing a second set ofpriority weights, wherein the second set of priority weights is used todetermine the priority for the ordered search for a request to retrievean application association for a file type.
 9. A set of computerreadable media according to claim 7, wherein each of the priorityweights includes a normal process owner weight, and wherein if one ofthe enabled layers is associated to a requesting process, the one of theenabled layers is prioritized according to the normal process ownerweight.
 10. A set of computer readable media according to claim 7,wherein said instructions are executable by the computing system tofurther provide the functions of: for the requests for the fileoperations originating from processes not associated to the enabledlayers, assigning a default weight to each of the enabled layers and thebase filesystem, for the requests for the file operations originatingfrom processes associated to a one of the enabled layers, assigning aprocess owner priority weight to the one of the enabled layers,assigning the default weight to a remaining number of enabled layers notassociated with the originating process, and assigning the defaultweight to the base filesystem, and for requests to retrieve anapplication association for a file type, prioritizing each of theenabled layers according to an application association priority weight.11. A set of computer readable media according to claim 7, wherein thepriority for write operations are different than the priority for readoperations.
 12. A set of computer readable media according to claim 7,wherein said instructions are executable by the computer system tofurther perform the functions of omitting enabled layers configured tobe read-only from the ordered search for the file object.
 13. A set ofcomputer readable media according to claim 7, wherein said instructionsare executable by the computer system to further perform the functionsof operating a layer manager application that commands enablement,disablement and importation of layers, wherein the layer managerapplication accepts commands from a network connection.
 14. A set ofcomputer readable media according to claim 13, wherein said instructionsare executable by the computer system to further perform the functionsof reporting the layers installed to the computer system to a networkrequester, and further wherein said instructions are executable by thecomputer system to further perform the functions of operating the layermanager application to receive layers from a network host, and commandenablement, disablement and importation of the layers.
 15. A method ofaccessing files in a base filesystem, the method comprising: receivingfrom an application a request to perform a file operation, the requestcontaining a file reference appropriate to the base filesystem,identifying a plurality of enabled layers and, for each of the enabledlayers, identifying a priority weight, determining a priority forsearching the enabled layers and the base filesystem, the priority basedupon each of the priority weights, performing a search for a file objectcorresponding to the file reference, the search performed in an orderdetermined by the priority, if, in performing the ordered search, thefile object is found corresponding to the file reference in one of theenabled layers, returning a virtual file handle to the file object, andif, in performing the ordered search, the file object is foundcorresponding to the file reference in the base filesystem, returning abase file handle to the file object.
 16. A method according to claim 15wherein each of the priority weights includes a second priority weight,and wherein the second priority weight is used for prioritizing arequest to retrieve an application association for a file type.
 17. Amethod according to claim 15 for prioritizing processes associated tolayers, wherein each of the priority weights includes a normal processowner weight, and wherein if one of the enabled layers is associated toa requesting process, the one of the enabled layers is prioritizedaccording to the normal process owner weight.
 18. A method according toclaim 15, said method further comprising: for the requests for the fileoperations originating from processes not associated to the enabledlayers, assigning a default weight to each of the enabled layers and thebase filesystem, for the requests for the file operations originatingfrom processes associated to a one of the enabled layers, assigning aprocess owner priority weight to the one of the enabled layers,assigning the default weight to a remaining number of enabled layers notassociated with the originating process, and assigning the defaultweight to the base filesystem, and for requests to retrieve anapplication association for a file type, prioritizing each of theenabled layers according to an application association priority weight.19. A method according to claim 15, wherein the priority for writeoperations are different than the priority for read operations.
 20. Amethod according to claim 15, wherein write operation layers configuredto be read-only are omitted from the ordered search for the file object.